Working Code Isn't Enough
「動くだけのコードは十分でない」
Strategic Programming vs Tactical Programming
優れた設計を目指すのであれば、Strategic Programming を選択する必要がある
Tactical Programming は、動作することを重視する
結果としてできるだけ早くタスクを終わらせようとする
そのため、より良い設計を求めることはしない
妥協の連続
これにより、システムの複雑さは増加していく
複雑さは漸進的
問題が起きたとしても、リファクタリングよりも目先の機能実装を優先する
より複雑さは増加していく
気がついたらその複雑さを一掃するには数ヶ月の作業が必要となる
後回しにして、目先の機能実装を優先する
無限ループってこわくね?
一度 Tactical Programming を選択すると、それを変更するのは難しい
Tactical Tornado
Tactical Programming を極限まで追求する開発者
組織に少なくとも一人はいる
他の人よりもはるかに速くコードを書き、機能を実装する
そのため、経営陣からは英雄視される
一方、(Tactical Tornadoの書いたコードに触れる)エンジニアから英雄視されることは無い
この歌詞私のことだ… radish-miyazaki.icon
優れた設計者になるための第一歩は、コードを書くだけでは十分ではない(Working Code Isn't Enough)であることを理解すること
目先の仕事を早く終わらせるためだけに、不必要な複雑さを導入すべきではない
大切なのは、将来行う拡張を容易にする長期的なシステムの構造(long-term structure of the system)
「動くコード」を第一の目標と考えるべきではない
動作するだけでなく、優れた設計を生み出す
Strategic Programming
Strategic Programming には投資のマインドセットが必要
プロジェクトを終わらせる最速の道を選択するではなく、システムの設計を改善するために時間を投資する
急がば回れ
短期的には開発スピードが下がるが、長期的には上がる
https://scrapbox.io/files/658012ae85a83300234374c3.png
e.g. 新しいクラスを追加する
いくつか代替案を考えて、将来変更しやすいものを選択する
e.g. 分かりやすいドキュメントを書く
ただし、いくら投資をしたところで設計上の判断に間違いがあるのは避けられない
時間が経てば、間違いは浮き彫りになる
少し時間をかけて修正するのが大切
継続的な投資
継続的なリファクタリング ∈ 継続的な設計
ここで無視したり、場当たり的に対応(Tactical Programming)するのはNG
Strategic Programming では、継続的に少しずつ改良を加えることが可能
Tactical Programming とは真逆
将来問題を引き起こす複雑な部分を少しずつ加える
システム全体を設計するような莫大な先行投資は効果的ではない
これはウォータフォールモデルであり、上手くいかないことが分かっている
最善なのは、継続的に小さな投資をたくさんすること
具体的には、総開発時間の 10% ~ 20% 程度
初期のプロジェクトでは、Tactical Programming よりも 10% ~ 20% 長くかかることになる
しかしながら、その分良い設計が生み出され、数カ月後にメリットを実感する
Tactical Programming を選択すると初期の開発スピードは早くなる
しかしながら、時間の経過とともに複雑さが蓄積され、開発スピードは遅くなる
スタートアップは Tactical Programming に走る傾向にある
成功すれば追加のエンジニアを雇う資金が手に入ると考え合理化する
ぶっ刺さる radish-miyazaki.icon
しかし、大抵修正することもできずにプロダクトの寿命が尽きるまで高い開発コストを支払い続ける羽目に
Strategic Programming に切り替える余裕も無いので詰む
企業が成功するための重要な要素は、優秀なエンジニアを雇うことである
優秀なエンジニアは優れた設計に拘る
酷いコードだとその噂が広まり、採用が難しくなる
システム構造が更に劣化する
負のスパイラル
どちらの選択をとっても成功することは可能であり、前例もある
Tactical Programming を採用した企業の例: Facebook(Meta)
長年 Move fast and break things がモットーであった
新人エンジニアであっても入社1週間目には本番環境にコミットするのが普通
エンジニアに大きな裁量があり、評判となった
グロースしたが、Tactical Programming を選択したので、多くのコードが不安定で理解しづらく、コメントやテストも少なく、複雑であった
最終的にはエンジニアに優れた設計にもっと投資することを奨励
モットーを Move fast with solid infrastructure に変更
https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-break-things-isnt-how-we-operate-anymore/
Facebook のレベルですらこのような状態に陥る radish-miyazaki.icon
Strategic Programming を採用した企業の例: Google, VMware
ソフトウェア設計に気を配って、クリーンなコードを持つ会社で働いたほうが楽しい
これは確かにそう radish-miyazaki.icon
hr.icon
要約
良い設計は、小さな継続的な投資 によって実現される
Strategic Programming を採用し、投資を明日ではなく今日行うものと考えるのが肝
一度設計の改善を先延ばしにすると、Tactical Programming に陥りやすくなる
先延ばしにすればするほど、問題は大きくなり、収集がつかなくなる
負のスパイラル
#読書メモ #複雑さ